As is known, a data model may be used to represent one or more sets of data. By way of example, the one or more sets of data represented by the data model may be associated with a data storage system.
The use of a data model facilitates the planning of the data storage system as the system goes through different states during a set of configuration changes. It is to be understood that a data storage system may be a data center, multiple data centers, or a part of a data center. The ability to simulate a change to a representation of the data center is referred to as “modeling” of the data associated with the data center while actually implementing a change to the data center is referred to as “migration.” For example, an administrator can model what a data center would look like given a proposed change to certain resources of a data storage system, while the actual implementation of the resource change would be considered a migration.
By way of example, a configuration change in a data center may involve the migration of a block of data from one storage array in the data center to another storage array in the data center. A data model is used in such migration planning operations.
EMP is a desktop tool for planning migrations of block data from array to array. Atlas is a web-hosted version of EMP with similar functionality. Both of these migration tools require the ability to model hypothetical states of data in the storage arrays/devices as the data will be migrated in stages. Several stages are planned in advance. It is typically necessary to be able to review, report on, and generate scripts relating to each hypothetical state. In these existing tools, states have a nominal date-range associated with them, and these date-ranges may not overlap. There is an implicit chronological order relating the states, i.e., changes in any state must propagate to the next state, and in a chained manner to all subsequent states.
In EMP and Atlas, each hypothetical state is modeled as a full copy of the data model, i.e. each state is persisted to a dedicated (relational) database. While this provides for rapid access to the data model for a given state, there are disadvantages such as, but not limited to: (i) a large amount of duplicate data is stored since the vast majority of a data center model does not typically change between one state and the next; (ii) changes made to a given state must be applied multiple times as they propagate forward, thus carrying a huge performance cost; and (iii) this existing approach obstructs multi-tenancy within a persistence layer.